Internet Info 1993

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / networking / terms / kermit / d / k10mit.bwr < prev next >

Wrap

Internet Message Format | 1991-06-05 | 24.4 KB

Date: 22 Apr 86 20:48 +0200 From: Sven_Olofsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA To: "Frank da Cruz" <SY.FDC@CU20B.COLUMBIA.EDU> Subject: Kermit-10 Problem: .run k10mit TOPS-10 KERMIT version 3(134) Kermit-10>set file (parameter) byte-size (to) 7 ? Unrecognized switch or keyword: "7" Kermit-10>set file (parameter) byte-size (to) ? one of the following: 7-bit 36-bit 8-bit auto-byte eight-bit seven-bit thirty-six-bit Diagnosis: The command table is not sorted properly. The new "36-bit" parameter comes after "7-bit". It should be vice versa. Cure: exchange two lines in the table FBS020 in K10MIT.MAC [Ed. - Thanks, change made in K10MIT.MAC source.] ------------------------------ . From BPA . Postmark:09-Dec-87:08:25:04 . To MAILER . Expires:08-Jan-88:08:24:17 . Subject: jnet%"fdccu@cuvma" From: Michael Freeman Re: Bugs/Bug Fixes for Kermit-10 Have discovered/fixed two bugs in Kermit for the DECsystem-10. Both occur in the MACRO-10 module K10MIT.MAC. (1) The new byte-size "TIRTY-SIX-BIT" does not work. Cause: In routines GET%FILE and PUT%FILE, when checking for operation in 36-bit mode, the wrong symbol is used in the comparison instruction. Fix: In routines GET%FILE and PUT%FILE, substitute the symbol $FBS36 for $FBS8 in the mode comparison instructions. Also fix comment in the routine PUT%FILE to correctly reflect the results of the test for the presence/absence of the high-order bit in a character. (2) In the routine T$CON which connects a terminal, when checking for connect to a non-network terminal, the wrong flavor of a compare instruction is generated by a CAX?? macro expansion. Fix: Place an extra pair of angle-brackets around the 2nd operand to the CAX macro so that the comma in the XWD pseudo-op argument doesn't confuse expansion of the CAX macro. I have not changed the edit-numbers as I was not sure of the editing scheme it was desired to use (for example, although edit 134 is mentioned in the .MEM files which accompany the DECsystem-10 Kermit distribution, KEREDT is set to 133 in my copy of K10UNV.MAC. Below is a FILCOM showing the differences in the code between the released K10MIT.MAC and the corrected version: File 1) DSKE:K10MIT.MAC[10,51] created: 0919 25-Nov-87 File 2) DSKE:K10MIT.MAC[10,51,NEW] created: 1341 25-Nov-87 1)83 CAXE S1,$FBS8 ;[127] Is this 36 bit? 1) BLSRET NORMAL ; Give a good return **** 2)83 CAXE S1,$FBS36 ;[127] Is this 36 bit? 2) BLSRET NORMAL ; Give a good return ************** 1)84 CAXN S2,$FBS8 ;[127] 36 bit? 1) TRNN S1,200 ; No, is the high order bit on? 1) BLSRET NORMAL ; No, Give a good return **** 2)84 CAXN S2,$FBS36 ;[127] 36 bit? 2) TRNN S1,200 ; Yes, is the high order bit on? 2) BLSRET NORMAL ; No, Give a good return ************** 1)106 CAXE S1,<XWD .NDTCN,T1> ; Non-network system? 1) JRST TCON.E ; No, some other error **** 2)106 CAXE S1,<<XWD .NDTCN,T1>> ; Non-network system? 2) JRST TCON.E ; No, some other error ************** Incidentally, the impending demise of VMSMIT Kermit (Kermit-32) raises the question of the fate of Kermit-10, although it could be argued that it will be doomed anyway with the slow and painful death of the KL10. What of support of Kermit-10? Keep up the fine work you are doing for the Kermit community. Regards, Michael Freeman (MORF) Bonneville Power Administration P.O. Box 491 Vancouver, WA 98666 (206)690-2307 (Reply via BITNET to address MAILER@UWALOCKE with subject dec10%"bpa") ------------------------------ . From BPA . Postmark:18-Mar-88:14:01:26 . To MAILER . Expires:17-Apr-88:13:58:57 . Subject: bitnet%"fdccu@cuvma" Re: Problem and Fix for TOPS-10 Kermit Problem: .SET WATCH FILES .RUN K10MIT [FL21: DSKD0:KERMIT.INI[5,34]] [FL21: DSK:KERMIT.INI[10,50], error 0] TOPS-10 KERMIT version 3(134)-7 Kermit-10>TAKE WARN.INI /DISPLAY [FL21: DSKE0:WARN.INI[10,50]] Kermit-10>TAKE WARN.INI /DISPLAY Kermit-10>SET FILE WARNING ON ?Stopcode - ILM - in module GLXINT on 18-Mar-88 on 13:18:49 Reason: Illegal memory reference at PC 555164 Program is KERMIT version 3(134)-7 using GLXLIB version 1(1172) Crash block starts at location 245 Last GLXLIB error: 1 (End of file) Diagnosis: If a system-wide Kermit initialization file (INI:KERMIT.INI) has been found and read but no initialization file exists in the user's area, the flag indicating that execution of an initialization file is in progress is not cleared, resulting in an incorrect path of execution being taken during the command parsing loop, leading to an Illegal Memory Reference. Cure: Clear the initialization-in-progress flag (INIIFN) before executing the $RETIF return macro. Below is shown a FILCOM which illustrates this: File 1) DSKE:K10MIT.MAC[10,50,KERMIT,TOPS10,OLD] created: 1346 25-Nov-87 File 2) DSKE:K10MIT.MAC[10,50,KERMIT,TOPS10] created: 1159 18-Mar-88 1)34 $RETIF ; Just punt if none 1) MOVEM S1,INIIFN ; Save the IFN **** 2)34 JRST [SETZM INIIFN ; Just clear the IFN 2) $RETIF] ; and punt if none 2) MOVEM S1,INIIFN ; Save the IFN ************** Keep up the good work! Cheers! Mike Freeman (routing MORF) Bonneville Power Administration P.O. Box 491 Vancouver, Wa 98666 Telephone (206)690-2307 Reply via BITNET to MAILER@UWALOCKE with subject-line dec10%"bpa" ------------------------------ . From BPA . Postmark:29-Aug-89:13:42:45 . To MAILER . Subject: bitnet%"fdccu@cuvma" re: Problems with Kermit for the DECsystem-10 Problem: .SET WATCH FILES .R KERMIT [FL21: DSKD0:KERMIT.INI[5,34]] [FL21: DSKE0:KERMIT.INI[10,50]] ? ?Illegal UUO at user PC 434262 . Diagnosis: The fix in K10MIT.BWR for the problem encountered when TAKEing files after INI:KERMIT.INI has been read but no KERMIT.INI exists in the user's PPN caused Kermit to become confused when a KERMIT.INI *did* exist in the user's PPN after INI:KERMIT.INI had been read. Cure: In the module K10MIT.MAC, make the changes shown in the FILCOM below. Both the original problem and the one its fix caused are eliminated. File 1) DSKE:K10MIT.MAC[10,50] created: 1029 22-Aug-89 File 2) DSKE:K10MIT.MAC[10,50,KERMIT,TOPS10] created: 1000 22-Aug-89 1)34 REDIN0: MOVX S1,<<SIXBIT |DSK|>> ;[125] Now we will use **** 2)34 SETZM INIIFN ; Again assume no .INI file 2) REDIN0: MOVX S1,<<SIXBIT |DSK|>> ;[125] Now we will use ************** 1)34 JRST [SETZM INIIFN ; Just clear the IFN 1) $RETIF] ; and punt if none 1) MOVEM S1,INIIFN ; Save the IFN **** 2)34 $RETIF ; Just punt if none 2) MOVEM S1,INIIFN ; Save the IFN ************** Problem: When Parity is set to None and the Block-check-type is set to 3-Character-CRC-CCITT, binary file transfers between Kermit-10 and Kermit running on microcomputers either fail or are incorrect. Diagnosis: In the module K10MSG.BLI, in the routine CALC_BLOCK_CHECK which calculates the block-check for a character-string, in the code for THE case in which the 3-Character-CRC-CCITT is used, there is an IF-clause which specifies the circumstances in which only seven bits of each eight-bit character are to be used in the Block-check calculation. As distributed, high-order bits of characters are to be ignored when Parity None is in effect. This is incorrect. The high-order bit of each character should be ignored when Parity is set to anything but None. Cure: In the module K10MSG.BLI, in the routine CALC_BLOCK_CHECK, in the 3-Character case, change the EQL in the IF-clause to a NEQ. A FILCOM showing the required change is shown below: File 1) DSKE:K10MSG.BLI[10,50] created: 1705 19-Aug-89 File 2) DSKF:K10MSG.BLI[10,50] created: 2214 20-Aug-89 1)45 IF .PARITY_TYPE EQL PR_NONE 1) THEN **** 2)45 IF .PARITY_TYPE NEQ PR_NONE 2) THEN ************** In the Macro-10 module K10MSG.MAC generated from K10MSG.BLI, the required change is accomplished as follows: (a) in the Bliss code which appears as Macro comments, in the routine CALC%BLOCK%CHECK, in the code for the 3-Character-CRC-CCITT case, in the IF clause, change the EQL to NEQ to correctly reflect the program logic. (b) in the Macro-10 code for this routine, change the statement TRNN AC2,1 which follows label L342: to TRNE AC2,1 Since I do not posess a Bliss-36 compiler, I am uncertain that this is the *exact* code that would be generated with this logic change but would assume so since, at this point in the program, AC2 is being used as a flag to indicate that Parity None is in effect. A FILCOM showing the required changes to the module K10MSG.MAC appears below: File 1) DSKF:K10MSG.MAC[10,50,KERMIT,TOPS10] created: 1105 07-Aug-86 File 2) DSKE:K10MSG.MAC[10,50] created: 1940 19-Aug-89 1)1 ; 5084 3 IF .PARITY%TYPE EQL PR%NONE 1) ; 5085 3 THEN **** 2)1 ; 5084 3 IF .PARITY%TYPE NEQ PR%NONE 2) ; 5085 3 THEN ************** 1)1 TRNN AC2,1 ; AC2,1 5084 1) JRST L.345 ; L.345 **** 2)1 TRNE AC2,1 ; AC2,1 5084 2) JRST L.345 ; L.345 ************** Please return mail to me via <mailer%uwalocke@bitnet.wiscvm.wisc.edu> with the subject "dec10%bpa". -- Mike Freeman, Bonneville Power Administration Vancouver WA, Telephone (206)690-2307 -- ------------------------------ Date: 09/26 23:57:35 From: KERMIT@cuvmb.cc.columbia.edu Subject: re: Problems with Kermit for the DECsystem-10 Problem: .SET WATCH FILES .R KERMIT [FL21: DSKD0:KERMIT.INI[5,34]] [FL21: DSKE0:KERMIT.INI[10,50]] ? ?Illegal UUO at user PC 434262 . Diagnosis: The fix in K10MIT.BWR for the problem encountered when TAKEing files after INI:KERMIT.INI has been read but no KERMIT.INI exists in the user's PPN caused Kermit to become confused when a KERMIT.INI *did* exist in the user's PPN after INI:KERMIT.INI had been read. Cure: In the module K10MIT.MAC, make the changes shown in the FILCOM below. Both the original problem and the one its fix caused are eliminated. File 1) DSKE:K10MIT.MAC[10,50] created: 1029 22-Aug-89 File 2) DSKE:K10MIT.MAC[10,50,KERMIT,TOPS10] created: 1000 22-Aug-89 1)34 REDIN0: MOVX S1,<<SIXBIT |DSK|>> ;[125] Now we will use **** 2)34 SETZM INIIFN ; Again assume no .INI file 2) REDIN0: MOVX S1,<<SIXBIT |DSK|>> ;[125] Now we will use ************** 1)34 JRST [SETZM INIIFN ; Just clear the IFN 1) $RETIF] ; and punt if none 1) MOVEM S1,INIIFN ; Save the IFN **** 2)34 $RETIF ; Just punt if none 2) MOVEM S1,INIIFN ; Save the IFN ************** Problem: When Parity is set to None and the Block-check-type is set to 3-Character-CRC-CCITT, binary file transfers between Kermit-10 and Kermit running on microcomputers either fail or are incorrect. Diagnosis: In the module K10MSG.BLI, in the routine CALC_BLOCK_CHECK which calculates the block-check for a character-string, in the code for THE case in which the 3-Character-CRC-CCITT is used, there is an IF-clause which specifies the circumstances in which only seven bits of each eight-bit character are to be used in the Block-check calculation. As distributed, high-order bits of characters are to be ignored when Parity None is in effect. This is incorrect. The high-order bit of each character should be ignored when Parity is set to anything but None. Cure: In the module K10MSG.BLI, in the routine CALC_BLOCK_CHECK, in the 3-Character case, change the EQL in the IF-clause to a NEQ. A FILCOM showing the required change is shown below: File 1) DSKE:K10MSG.BLI[10,50] created: 1705 19-Aug-89 File 2) DSKF:K10MSG.BLI[10,50] created: 2214 20-Aug-89 1)45 IF .PARITY_TYPE EQL PR_NONE 1) THEN **** 2)45 IF .PARITY_TYPE NEQ PR_NONE 2) THEN ************** In the Macro-10 module K10MSG.MAC generated from K10MSG.BLI, the required change is accomplished as follows: (a) in the Bliss code which appears as Macro comments, in the routine CALC%BLOCK%CHECK, in the code for the 3-Character-CRC-CCITT case, in the IF clause, change the EQL to NEQ to correctly reflect the program logic. (b) in the Macro-10 code for this routine, change the statement TRNN AC2,1 which follows label L342: to TRNE AC2,1 Since I do not posess a Bliss-36 compiler, I am uncertain that this is the *exact* code that would be generated with this logic change but would assume so since, at this point in the program, AC2 is being used as a flag to indicate that Parity None is in effect. A FILCOM showing the required changes to the module K10MSG.MAC appears below: File 1) DSKF:K10MSG.MAC[10,50,KERMIT,TOPS10] created: 1105 07-Aug-86 File 2) DSKE:K10MSG.MAC[10,50] created: 1940 19-Aug-89 1)1 ; 5084 3 IF .PARITY%TYPE EQL PR%NONE 1) ; 5085 3 THEN **** 2)1 ; 5084 3 IF .PARITY%TYPE NEQ PR%NONE 2) ; 5085 3 THEN ************** 1)1 TRNN AC2,1 ; AC2,1 5084 1) JRST L.345 ; L.345 **** 2)1 TRNE AC2,1 ; AC2,1 5084 2) JRST L.345 ; L.345 ************** Please return mail to me via <mailer%uwalocke@bitnet.wiscvm.wisc.edu> with the subject "dec10%bpa". -- Mike Freeman, Bonneville Power Administration Vancouver WA, Telephone (206)690-2307 -- ------------------------------ Date: Wed, 11 Jul 90 11:23 PDT From: <MAILER@UWALOCKE> Subject: dec10%"BPA" originated mail follows:- To: fdccu@cuvma Original_To: JNET%"fdccu@cuvma" . From BPA . Postmark:11-Jul-90:11:11:03 . To MAILER . Expires:10-Aug-90:11:10:03 . Subject: jnet%"fdccu@cuvma" Re: Updated Helpfile for TOPS-10 Kermit I have updated the help file for TOPS-10 Kermit, K10MIT.HLP, to reflect the latest version of Kermit-10 (Version 3(134)). The file includes text showing the THIRTY-SIX-BIT file byte-size as well as long packet support. A FILCOM of the original help file (as found on OKSU dial-up) with my revision is shown below, delimited by lines of asterisks. Following this, delimited by asterisks, is a .COR-file (K10HLP.COR) produced by the TOPS-10 program COMPAR, which, when applied to the original file K10MIT.HLP with the TOPS-10 program UPDATE, will produce an updated help file. Incidentally, I had to do extensive reformatting of the source-files (MACRO-10 versions) as found on OKSU due to <CR><LF> pairs being inserted in many places when lines were longer than 80 characters (which raised havoc with compilation). In order to make this version function properly, one should also make my modifications to K10MIT.MAC to fix bugs in handling of .INI-files, the THIRTY-SIX-BIT byte-size and NODE. UUO arguments. Thanks for the latest newsletter. keep up the good work. Send E-mail to me with BITnet address mailer@uwalocke with the message subject dec10%"bpa". This is necessary to get the mail from the BITnet node uwalocke (a Vax) to the DECsystem-10 to which I have access. Michael Freeman Routing MORF Bonneville Power Administration P.O. Box 491 Vancouver, WA 98666 (206)690-2307 [Ed. - NOTE: some of the lines below were longer than 80 characters, and had spurious CRLFs inserted. To make them fit within 80 characters, some blanks were deleted, which will interfere with the formatting and and will probably invalidate the checksum at the end.] ************************************************************************ File 1) DSKE:K10MIT.HLP[10,50,K10MIT,NEW] created: 1044 22-Jun-90 File 2) DSKE:KERMIT.HLP[10,50,K10MIT,NEW] created: 1024 10-Jul-90 1)1 used as text files on the TOPS-10 system. SEVEN-BIT should 1) also be used to sending TOPS-10 format binary files to 1) another system if the file is intended to be brought to a 1) TOPS-10 system. EIGHT-BIT bytes should be used for binary 1) files from other systems (such as CP/M .COM files) which are 1) being transferred to the TOPS-10 system for storage. This 1) allows the file to be returned without any changes. 1) AUTO-BYTE is the same as SEVEN-BIT for files being received 1) from the other Kermit. When sending a file with FILE 1) BYTE-SIZE AUTO-BYTE, Kermit-10 will guess whether the file 1) should be sent as SEVEN-BIT or EIGHT-BIT. This guess is 1) based on the mode used to write the file. If the file was 1) written in image mode, image binary mode, binary mode, or **** 2)1 used as text files on the TOPS-10 system. EIGHT-BIT bytes should be 2) used for binary files from other systems (such as CP/M .COMfiles) 2) which are being transferred to the TOPS-10 system for storage. This 2) allows the file to be returned without any changes. 2) THIRTY-SIX-BIT should be used to sending TOPS-10 format 2) binary files to another system if the file is intended to be 2) brought to a TOPS-10 system. AUTO-BYTE is the same as SEVEN-BIT for 2) files being received from the other Kermit. When SENDing a 2) file with FILE BYTE-SIZE AUTO-BYTE, Kermit-10 will guess whether 2) the file should be sent as SEVEN-BIT or EIGHT-BIT. This guess 2) is based on the mode used to write the file. If the file was 2) written in image mode, image binary mode, binary mode, or ************** 1)1 Where type is SEVEN-BIT, EIGHT-BIT or AUTO-BYTE. 1) *SET FILE NAMING **** 2)1 Where type is SEVEN-BIT, EIGHT-BIT, THIRTY-SIX-BIT or AUTO-BYTE. 2) *SET FILE NAMING ************** 1)1 10 and 96. Packet lengths outside of this range are 1) illegal. The default value is 80. **** 2)1 10 and 1000. Packet lengths outside of this range are 2) illegal. The default value is 80. ************** 1)1 value for this parameter must be between 10 and 96. Packet 1) lengths outside of this range are illegal. The default **** 2)1 value for this parameter must be between 10 and 1000. Packet 2) lengths outside of this range are illegal. The default ************** ************************************************************************ REP 713/1 used as text files on the TOPS-10 system. SEVEN-BIT should also be used to sending TOPS-10 format binary files to another system if the file is intended to be brought to a TOPS-10 system. EIGHT-BIT bytes should be used for binary files from other systems (such as CP/M .COM files) which are being transferred to the TOPS-10 system for storage. This allows the file to be returned without any changes. AUTO-BYTE is the same as SEVEN-BIT for files being received from the other Kermit. When sending a file with FILE BYTE-SIZE AUTO-BYTE, Kermit-10 will guess whether the file should be sent as SEVEN-BIT or EIGHT-BIT. This guess is based on the mode used to write the file. If the file was WIT used as text files on the TOPS-10 system. EIGHT-BIT bytes should be used for binary files from other systems (such as CP/M .COM files) which are being transferred to the TOPS-10 system for storage. This allows the file to be returned without any changes. THIRTY-SIX-BIT should be used to sending TOPS-10 format binary files to another system if the file is intended to be brought to a TOPS-10 system. AUTO-BYTE is the same as SEVEN-BIT for files being received from the other Kermit. When sENDING A file with FILE BYTE-SIZE AUTO-BYTE, Kermit-10 will guess whether the file should be sent as SEVEN-BIT or EIGHT-BIT. This guess is based on the mode used to write the file. If the file was REP 739/1 Where type is SEVEN-BIT, EIGHT-BIT or AUTO-BYTE. WIT Where type is SEVEN-BIT, EIGHT-BIT, THIRTY-SIX-BIT or AUTO-BYTE. REP 927/1 10 and 96. Packet lengths outside of this range are WIT 10 and 1000. Packet lengths outside of this range are REP 1047/1 value for this parameter must be between 10 and 96. Packet WIT value for this parameter must be between 10 and 1000. Packet SUM 206663 ************************************************************************ > Paul West had a problem entering > server mode. He types "server" to the Kermit-10 prompt and gets message > "? Kermit-10 Devsize UUO failure (-1)" and then the Kermit-10 prompt > comes back. Any idea what's going on with this? > He called back today and said he'd solved the problem. He used DDT, a tops-10 macro debugger, and ended up commenting out two lines in module T$CONN: (which I see is in the file k10mit.mac). The two consecutive lines he commented out are: CAXE S1,<XWD .NDTCN,T1> ; Non-network system? JRST TCON.E ; No, some other error He says the problem was "the tty was an invalid tty", removing those two lines fixed it for him. FYI. ------------------------------ Date: Thu, 6 Jun 91 13:43:56 EDT From: Mike Freeman <freeman@watsun.cc.columbia.edu> Subject: Kermit-10 Problem Well, I wonder if he's got the latest version of Kermit-10. As I recall, I ran into this when I tried to compile the latest Kermit-10 (the one with extended-length packets) and the problem was due to some lines in K10MIT.MAC having been broken up in transmission to watsun. I've uploaded corrected files. Have the gentleman FTP ~/kermit/b/k10*.mac to his site and try again. If he's still having trouble, let me know and I'll look into it. Alternatively, I can E-mail you a little Fortran program to run on the Ten along with an ASCII representation of the SIXBIT translation of KERMIT.EXE from our site that he can use the program to convert back into KERMIT.EXE and try out. We won't be a DECsystem-10 site much longer (sigh) so after a few more weeks won't be able to help him directly (though I'll keep source around for awhile). BTW, the versions of the Galaxy universals used by K10MIT.MAC aren't the latest ones -- they changed the def of the STOPCD macro so MACRO complains using the latest ones. I can supply translated versions of the one's K10MIT.MAC likes if needed. By the way, those lines can be left in if <> is replaced by <<>> -- so that the arguments to the macro get translated properly (later as one arg rather than two). ------------------------------